Posts

Post not yet marked as solved
6 Replies
Yes, I did use the latest version of Xcode, but actually an update to 10.15 Catalina resolved the problem with the debugger.Now the Capture and Debugging works, but at the pixels within the Artefact the debugger shows a different return value for the fragment shader (the correct one!) than the (wrong) value in the output. See new screenshot at https://nc.fhoermann.org/index.php/s/aM86J4g5LXHQYRZEven debugging several different pixels (within the artefact) several times I was not able to produce the error in the debugger. PS. Sorry, I introduced typos in the shader code posting it, I'll try to edit that.
Post not yet marked as solved
6 Replies
I tried the capure and indeed the artefacts are still there and change from frame to frame in the Xcode-Window displaying the colorAttachment (that is, they change for the same capture each time Xcode redisplays the output). The debugging however does not work; not even for the sample project: "https://developer.apple.com/documentation/metal/migrating_opengl_code_to_metal?language=objc". The error message is:Unable to create shader debug sessionError DYPShaderDebuggerErrorDomain:2:Error creating instrumented render pipeline state: Error Domain=CompilerError Code=1 "Link failed: fragment shader is reading the render_target_array_index but the vertex shader does not write it" UserInfo={NSLocalizedDescription=Link failed: fragment shader is reading the render_target_array_index but the vertex shader does not write it}Of course there is no "render_target_array_index" specified anywhere in the Shader.I have no idea what's happening, nor whether this is related to the problem we are discussing.
Post not yet marked as solved
6 Replies
Thanks a lot for your suggestion. I tried this already before and also rendered the scene with ca. 1fps waiting half a second after and before the calls to replaceRegion: to make sure that it is not a problem related to syncronization. The same effect occurs.(- of course the textures used for replaceRegion were supposed to be old ones anyway, not being in a render pipeline for a significant time - the test was to make sure that there is no mistake in the part of the program organizing this)